Wireless LAN access networks are being deployed in public places such as airports, hotels, shopping malls, and coffee shops by a diverse set of operators such as cellular carriers, wireless Internet service providers and fixed broadband operators. These networks are referred to herein as public wireless local area networks (PWLANs).
When a user executes the network access authentication procedure to such a network, information about the location and operational ownership of this network is conveyed to the user's home network to which the user has a contractual relationship.
PWLAN service providers have expressed interest in offering location-based services using WISPr attributes. The location of a wireless client is based on the AP with whom the client is associated. This location can be configured on the AP and carried through the network using the Location-ID and Location-Name RADIUS vendor-specific attributes (VSAs) recommended by the Wi-Fi Alliance WISPr hot-spot service provider roaming initiative. The attributes are included in “Accounting Request” (Start/Update/Stop), “Access Request” and “Access Accept” messages. A client's location can be used in public access networks to display logon page and enforce white lists based on client's location; to enable auto-logon services based on client's location; to bill a client with a tariff that varies based on his location; to support roaming billing arrangements between service providers; and other applications. The location attributes can be used by a number of application servers. Such application servers generally functions as portals, billing servers, subscriber service repository or policy enforcement points.
When subscriber edge services manager (SESM) is used to offer portal services, it needs the location information of a user (based on AP within a hot spot) in order to present a user a web page that may be access location dependent. In the wholesale model, this is commonly used to provide portals from different providers to the user. This tailors the portal to a specific location or group of interest, such as an airport lounge or a hotel chain. The SESM also needs the location information to implement an accepted URL that is known in the art as a “white URL” per each location, and also to automatically associate services to a user based on his location.
Prior solutions have relied on a L2 Switch relaying switch/port ID using option 82 so DHCP server can associate specific address ranges to an AP. However, this approach suffers serious shortcomings. This solution is difficult to administer, as the application server using this information to offer location-based service must be reconfigured every time an AP is added or moved. Such application servers must often correlate different address ranges and then apply same policies across these different address ranges. Also, a L2 Switch is not always used between an AP and an AZR. Finally, the approach simply does not work for static IP users.